PC Welt 1997 July

home *** CD-ROM | disk | FTP | other *** search

/ PC Welt 1997 July / Freeware CD.iso / FREEWARE / !utils / sfs / SFS117!.EXE / SFS3.DOC < prev next >

Wrap

Text File | 1995-03-20 | 59.5 KB | 1,206 lines

Advanced SFS Driver Options --------------------------- The SFS driver supports several advanced options which can be used to customize the operation of SFS. These include the ability to mount SFS volumes automatically when the driver is loaded, the ability to echo passwords to the screen as they are entered, and the ability to change the read/write status, disk access mode, auto-unmount timeout of mounted volumes, quick-unmount hotkey, and the password prompt used when mounting volumes. Mounting SFS Volumes at System Startup You can mount SFS volumes automatically when the system is started up rather than having to use the mountsfs program or SFS Control Panel item by using the `MOUNT=<identification number>' option when the SFS driver is loaded. The <identification number> is the 8- or 14-digit volume identification number displayed by mksfs when the encrypted volume is created or shown when you use the `mountsfs information' command. The volume identifier is used to tell the SFS driver which volume to load. If the volume allows multiuser access, only the volume administrator can mount it. Normal volume users must follow the standard volume mount procedure using mountsfs. The operation of shared SFS volumes is explained in more detail in the section "Sharing SFS Volumes Between Multiple Users" below. If access to the volume is controlled with a smart card key then you must mount it using mountsfs, as the SFS driver does not have enough information available to it to allow a mount using a smart card. If you try to mount a volume which uses a smart card key, the driver will display: Error: Volume uses a smart card key, use mountsfs to mount it and skip the mount procedure. When you mount a volume at the time the SFS driver is loaded you can use the shorter 8-digit volume identifier in most cases, but may need to use the longer 12-digit form for volumes with more complex access procedures such as ones on SCSI drives. mksfs and mountsfs will always print the correct type of identifier for the volume in question, and this is the one which you should use after the `MOUNT=' option. For example if mksfs displays the 8-digit volume identifier `530A17FD' for a particular volume then the command to mount this volume would be: DEVICE=SFS.SYS MOUNT=530A17FD If it displays a 14-digit volume identifier `C02100142DE0FC' then the command to mount the volume would be: DEVICE=SFS.SYS MOUNT=C02100142DE0FC If you supply an incorrect volume identifier, the driver will display Error: Invalid mount ID, skipping mount and skip the mount procedure. If the volume identifier is correct, the driver will locate the required volume on the disk and try to read in the information needed to process it. If this information cannot be read or is incorrect, the driver will display: Error: Invalid SFS volume information, skipping mount and skip the mount procedure. If the volume is located on a SCSI drive and the SCSI manager software needed to access the drive is not present, the driver will display: Error: SCSI manager not found, cannot mount SCSI drive and skip the mount procedure. If all is correct the driver will ask for the password exactly as mountsfs would: Please enter password (10...100 characters), [ESC] to quit: You can now enter the password, which for security reasons is not echoed to the screen. You can correct any typing errors with the backspace key, and use the Esc key to quit. The software will check for a password longer than the maximum of 100 characters or an attempt to backspace past the start of the password, and beep a warning when either of these conditions occur. You are allowed up to three attempts at entering the correct password before the mount is skipped. If you use the Esc key to skip the password entry, the SFS driver will print: Mount operation skipped at user request and skip the mount procedure. Otherwise, once you have entered the password, the SFS driver will process it and, if an incorrect password is detected, will print: Error: Incorrect password, skipping mount and skip the mount procedure. Otherwise, the driver will perform a quick disk read test to make sure everything is working correctly. If this fails, the driver will display: Error: Disk read test failed, skipping mount and skip the mount procedure. If the disk read test is successful, the encrypted volume will be mounted ready for use, with the drive letter being the next available DOS drive. In general the mount procedure is the same as the one which mountsfs uses, except that the full functionality of mountsfs is not available during the mount. In all cases if the mount procedure is skipped the driver will still be loaded so that you can mount volumes at a later time with mountsfs or the SFS Control Panel item if required. The mount procedure has a built-in timer which expires if no key is hit for more than 1 minute. This is to allow unattended machines to automatically reboot in case of a power failure without waiting forever for a mount password. If no key is pressed for more than 1 minute, the SFS driver will print: Password entry timed out, skipping mount and skip the mount procedure. Again, the driver will still be loaded to allow you to mount volumes at a later time. Once the volume has been mounted and after the usual SFS installation message has been displayed, the driver will display the DOS drive on which the encrypted volume is mounted. For example if the volume was available as drive G: the message would be: Encrypted volume is now mounted as drive G: If necessary you can swap the drive letter which SFS uses with the JSWAP utility which comes as part of the JAM disk compression software. The use of JSWAP rather than the DOS commands ASSIGN, SUBST, and JOIN, or other third-party utilities such as the one provided with Stacker are recommended, as JSWAP provides the safest means of swapping drive letters. In particular, JSWAP won't swap any non-physical drives, it won't reassign physical drives to leave a hole in series of block devices (as opposed to the way DoubleSpace does things), and it tries to ensure that the occasional program which doesn't normally handle drive swapping too well should still work. You can also use the JDRIVE utility to force SFS to use a given drive or drives to mount volumes on, instead of simply using the next drive letter provided by DOS. For example, to force the SFS to use the M: drive to mount the volume in the previous example, the command would be: DEVICE=JDRIVE.COM M: DEVICE=SFS.SYS MOUNT=530A17FD More information on the JAM utilities is given in the section "Creating Compressed SFS Volumes" below. To mount multiple volumes, you should specify the mount identifiers in the order in which the volumes are to be mounted. For example if you wanted to mount a second SFS volume with the volume identifier `4850414B' then the previous example would change to: DEVICE=SFS.SYS MOUNT=530A17FD MOUNT=4850414B As more volumes are mounted, the driver will automatically increase the mount point allocation until the maximum number of 5 mount points has been reached, making use of the `UNITS=n' option unnecessary. If you try to mount more than 5 volumes, the driver will print: Error: No more disk units available for mount and skip the mount procedure. You can create an almost completely encrypted SFS system by using the JCHAIN utility which is part of the JAM disk compression software to allow a boot into an encrypted SFS volume. To do this, create a small (say 1MB) bootable partition which contains the DOS system files IO.SYS and MSDOS.SYS, the drivers SFS.SYS and JCHAIN.SYS files, and the following CONFIG.SYS: DEVICE=SFS.SYS MOUNT=<identification number> DEVICE=JCHAIN.SYS D:\CONFIG.SYS You can install the system files onto the newly-created partition by formatting it with: FORMAT /S and then deleting the COMMAND.COM file which format copies onto the partition. This setup will load the SFS driver from the small partition, mount the encrypted volume (in this case as drive D:), and then continue the boot process from the encrypted volume. If you want to load the SFS driver into high memory, you will need to add memory managers such as HIMEM.SYS and EMM386.EXE to the files on the small bootable partition, and change the CONFIG.SYS file to: DEVICE=HIMEM.SYS DEVICE=EMM386.EXE DEVICEHIGH=SFS.SYS MOUNT=<identification number> DEVICE=JCHAIN.SYS D:\CONFIG.SYS There is no need to load JCHAIN high as this program is only used to chain to the CONFIG.SYS file on the encrypted volume and doesn't stay resident in memory. Setting the Quick-Unmount Hotkey Value When a volume is mounted, the quick-unmount hotkey is by default set to a combination of the left and right shift keys. However, like the mountsfs `hotkey=' option, the SFS driver supports user-defined hotkeys with the `HOTKEY=quick-unmount hotkey' command, as well as allowing the hotkey unmount option to be disabled with the `HOTKEY=NONE' command. You can use the `HOTKEY=quick-unmount hotkey' form of the command to specify any combination of the left shift key, right shift key, control key, alt key, and a letter key, in the following manner: Alt key = `alt' Control key = `ctrl' Left shift key = `leftShift' Right shift key = `rightShift' Letter key = `a'...`z' You should seperate the key combinations with hyphens, `-'. The key names themselves are not case sensitive and can be given in upper or lower case, or a mixture of both. If you use an unknown key name or the key names are not separated with hyphens, the SFS driver will complain: Error: Bad quick-unmount hotkey format For example, to specify the use of the left shift and right shift keys as the quick-unmount hotkey (the usual default setting), the command used in the previous example would be changed to: DEVICE=SFS.SYS MOUNT=530A17FD HOTKEY=LEFTSHIFT-RIGHTSHIFT To use the Control, Alt, and Z keys as the quick-unmount hotkey without mounting any volumes the command would be: DEVICE=SFS.SYS HOTKEY=CTRL-ALT-Z To disable hotkey unmounting altogether, and without mounting any volumes, the command would be: DEVICE=SFS.SYS HOTKEY=NONE Echoing the Mount Password to the Screen Normally when the mount password is entered, nothing will be echoed to the screen. If you want to have the password echoed to the screen as you type it in, you can use the `ECHO' option to turn on the echoing of passwords. Note that the use of this option makes it much easier for someone to eavesdrop on the password as you enter it, by simply glancing over your shoulder, by making use of monitoring facilities installed for general security purposes, or by using more sophisticated techniques such as TEMPEST monitoring (these are covered in more detail in the section "Data Security" below). For these reasons, use of the `ECHO' option is not recommended. Changing the Mount Password Prompt In some environments it may be undesirable to alert others to the fact that disk encryption is being used. Using the `SILENT' option with the driver removes most indications of the presence of SFS, but if you mount volumes when the system is started up the appearance of the password prompt may still give things away. To correct this problem, the SFS driver supports user-definable prompts with the `PROMPT=user-prompt' command. You can use this to specify any single-word prompt, or, if the prompt is surrounded by quotation marks `"', any combination of characters until another `"' is encountered. For example to make the SFS mount procedure appear like a network login, the previous mount example might be changed to: DEVICE=SFS.SYS SILENT PROMPT=Login: MOUNT=530A17FD Instead of the usual password prompt, the driver will now display: Login: when it asks for the password. If you prefer a prompt containing multiple words, you should surround the prompt itself with quotation marks: DEVICE=SFS.SYS SILENT PROMPT="Please log on:" MOUNT=530A17FD Unfortunately some versions of DOS convert all characters to uppercase before passing them to SFS.SYS. In order to allow lowercase characters to be used in prompts, the `PROMPT=' option recognises the escape sequence `\s' to mean "shift to lowercase", so that all subsequent characters will be converted to lowercase before being displayed. Subsequent uses of `\s' will toggle the current shift state, shifting characters back to uppercase or to lowercase depending on the current shift state. For example to have the previous mount example display the prompt "Enter Code:", the command would be: DEVICE=SFS.SYS SILENT PROMPT="E\sNTER \sC\sODE:" MOUNT=530A17FD The initial "E" is displayed in uppercase, then the first `\s' shifts the "NTER" to lowercase, the second `\s' shifts the "C" back to uppercase, and the final `\s' shifts the remaining "ODE:" to lowercase. The `PROMPT=' option also recognises a number of other escape codes which you can use to specify characters which cannot be directly entered into the CONFIG.SYS file such as quote marks, tabs, and line breaks. These are based on the ones used in the C programming language, and are as follows: Newline = \n Quote mark = \" Bell = \a Tab = \t Backspace = \b Escape = \e For example to print a line break as part of a prompt, you can use the escape code '\n', allowing prompts to be split over multiple lines, or simply to have blank lines as part of the prompt. An extended form of the above prompt (split over two lines for clarity) could be given as: DEVICE=SFS.SYS SILENT PROMPT="Network logon\nPlease enter password:" MOUNT=530A17FD which would be printed as: Network logon Please enter password: You can use the `\e' escape code in combination with an ANSI driver to allow special actions such as cursor positioning and colour and text attribute control. Most of the useful escape sequences begin with `\e[', corresponding to the "ESC [" combination. These codes only work if an ANSI driver is loaded by specifying DEVICE=ANSI.SYS or some other ANSI-compatible driver in CONFIG.SYS. Some of the possible codes are: ANSI sequence Action Default \e[row;columnH Move the cursor to (row, column) 1, 1 \e[row;columnf Move the cursor to (row, column) 1, 1 \e[rowd Move the cursor to (row) 1 \e[columnG Move the cursor to (column) 1 \e[countA Moves the cursor up (count) rows 1 \e[countB Moves the cursor down (count) rows 1 \e[countC Moves the cursor right (count) columns 1 \e[countD Moves the cursor left (count) columns 1 \e[2J Clears the screen and homes the cursor \e[K Clears from the cursor position to the end of the current line \e[M Clears the entire line \e[s Saves the current cursor position \e[u Restores the previously saved cursor position \e[countb Repeat following character (count) times 1 \e[attr;...;attrm Set screen attributes based on (attr). Possible values for the (attr) settings are: 30 Black foreground 40 Black background 31 Red foreground 41 Red background 32 Green foreground 42 Green background 33 Yellow foreground 43 Yellow background 34 Blue foreground 44 Blue background 35 Magenta foreground 45 Magenta background 36 Cyan foreground 46 Cyan background 37 White foreground 47 White background For example to clear the screen and home the cursor before printing the "Login:" prompt given previously, the command would be: DEVICE=SFS.SYS SILENT PROMPT=\e[2JLogin: MOUNT=530A17FD To print the prompt in black on a blue background, the command would be: DEVICE=SFS.SYS SILENT PROMPT=\e[30;44mLogin:\e[37;40m MOUNT=530A17FD The order in which these arguments are given is important, since an option only affects the other options following it. If you specify the `PROMPT=' option after the `MOUNT=' option instead of before it, the driver won't use the new prompt until after the mount has taken place. You can use this to allow multiple independant prompts when several volumes are mounted, so that in the following example (which is again split over two lines for clarity): DEVICE=SFS.SYS SILENT PROMPT="Local server logon: " MOUNT=C0EDBABE PROMPT="Printer server logon: " MOUNT=2A1102D3 the prompt "Local server logon: " would be used for the first volume to be mounted and the prompt "Printer server logon: " would be used for the second volume to be mounted. The `PROMPT=' setting applies for all further mounts until another `PROMPT=' option is given. Changing the Mount Read/Write Access Status You can enable or disable write access to a mounted volume in the same manner as is done through the use of the `mountsfs +r' and `mountsfs +rw' options (more information on read-only access to SFS volume is given in the section "Mounting an SFS Volume" above). In the case of the SFS driver, the options used to control write access are `READONLY' and `READWRITE'. For example to mount the volume used in the previous example read-only the command would be: DEVICE=SFS.SYS READONLY MOUNT=530A17FD Like the other options which affect the mounting of volumes, you must specify the `READONLY' or `READWRITE' options before the `MOUNT=' which they are to affect. These options apply for all further mounts until another `READONLY' or `READWRITE' option is given. For example to mount the first volume in the previous example read-only and the second one with normal write access the command would be: DEVICE=SFS.SYS READONLY MOUNT=530A17FD READWRITE MOUNT=4850414B Mounting Volumes as Non-Removable Drives Since SFS volumes may be unmounted at any point through a hotkey unmount, an auto-unmount timeout, a smart card unmount, or through the use of the mountsfs program or SFS Control Panel item, the driver reports them to the operating system as being removable volumes. This means that the system won't become confused when disk volumes suddenly cease to exist after an unmount. Unfortunately some software, while handling removable volumes perfectly well, prefers to work with non-removable or fixed volumes. An example of this is Windows, which won't display volume labels for removable volumes. Disk buffering and cacheing for fixed volumes is also somewhat better since the operating system doesn't have to worry about the volume being unmounted suddenly, leaving it with nothing to write buffered data to. The SFS driver lets you mount volumes as fixed volumes through the use of the FIXED keyword. By default, or if you use the REMOVABLE keyword, they are mounted as removable volumes. You must mount fixed volumes at system startup, and they will remain mounted until the system is either restarted or powered down. Hotkey, timed, smart card, mountsfs, and SFS Control Panel unmounts will *not* affect volumes mounted in this manner - they will remain mounted at all times. For example to mount the volume used in the previous example as a fixed, non-removable volume the command would be: DEVICE=SFS.SYS FIXED MOUNT=530A17FD Like the other options which affect the mounting of volumes, you must specify the `FIXED' or `REMOVABLE' options before the `MOUNT=' which they are to affect. These options apply for all further mounts until another `FIXED' or `REMOVABLE' option is given. For example to mount the first volume in the previous example as a fixed volume and the second one as a standard removable one the command would be: DEVICE=SFS.SYS FIXED MOUNT=530A17FD REMOVABLE MOUNT=4850414B Setting the Auto-unmount Timeout value The auto-unmount timeout value works just like the mountsfs `timeout=' option, and is used to tell the SFS driver to unmount a volume automatically if it has not been accessed for a certain amount of time. You can set the time delay until the volume is automatically unmounted with the `TIMEOUT=' option, which is used to specify the delay in minutes until the unmount takes place. This option can only be used in conjunction with the `MOUNT=' option, and by default no auto-unmount timer is set. The use of this option is only necessary if the volumes to be mounted have no timeout values associated with them, either by mksfs when the volume is created or by chsfs at a later point in time. However, you can also use the `TIMEOUT=' option to override any existing timeout settings for the volume. In order to return to the default timeout settings, you can use the `TIMEOUT=DEFAULT' option which sets the timeout of any volumes mounted after this point to either the value associated with the volume, or none at all if the volume has no timeout setting. To force the timeout setting to be disabled entirely, use the `TIMEOUT=NONE' option to ensure that no timeout is set for any volumes mounted after this point. As before, this option holds until another `TIMEOUT=' setting is used. You can display the timeout value associated with a volume with the `mountsfs information' command. Like the other options which affect the mounting of volumes, you must specify the `TIMEOUT=' option before the `MOUNT=' which it is to affect. The `TIMEOUT=' option applies for all further mounts until another `TIMEOUT=' option is given. Using the previous mount example, but to have a volume automatically unmounted after 15 minutes of inactivity, the command would be: DEVICE=SFS.SYS TIMEOUT=15 MOUNT=530A17FD The timeout period must be between 1 and 30,000 minutes (this means the upper timeout limit is around three weeks). If you specify a timeout value of less than 1 minute or greater than three weeks, mountsfs will exit with the error message: Error: Timeout value must be between 1 and 30,000 minutes If no accesses are made to a volume within the given time period, it will be automatically unmounted. Like the case when a hotkey unmount is made, a single beep will sound to indicate that the unmount has taken place. Each volume has its own timer, allowing you to give different volumes different lengths of time before they unmount, or to have no auto-unmount time at all. This is useful when, for example, one volume containing highly sensitive information needs to have a very short timeout, while another volume containing less secret information can have a much longer timeout. For example the two volumes used in the previous example might be mounted as follows: DEVICE=SFS.SYS TIMEOUT=10 MOUNT=530A17FD TIMEOUT=30 MOUNT=4850414B in which the first volume is given a short timeout of only 10 minutes while the second volume, which presumably holds less critical information, is given a longer timeout of half an hour. If the volumes have a timeout setting associated with them and you have used the `TIMEOUT=' option to override it, you can restore the default behaviour of using the setting associated with the volume by using the `TIMEOUT=DEFAULT' option. For example if, in the previous example, you wanted to use the default timeout setting for the second volume instead of overriding it with a 30-minute timeout, the volumes would be mounted as follows: DEVICE=SFS.SYS TIMEOUT=10 MOUNT=530A17FD TIMEOUT=DEFAULT MOUNT=4850414B This would mount the first volume as before, and the second volume with whatever timeout was set for it by mksfs or chsfs. If you wanted to mount the second volume with no timeout at all, the volumes would be mounted as follows: DEVICE=SFS.SYS TIMEOUT=10 MOUNT=530A17FD TIMEOUT=NONE MOUNT=4850414B Enabling Alternative Disk Access Modes SFS supports a number of faster disk access modes, which would normally be specified when the volume is created with mksfs, or set at a later date with the `chsfs newaccess=' command. However you may want to override these settings when volumes are mounted. You can do this with the `ACCESS=' option, which takes as an argument the fast access mode given by the `mksfs -c' command, or `bios' to specify the normal, somewhat slower access mode. You can display the access mode currently set for a volume with the `mountsfs information' command. For example if you created the volume in the previous example with no fast access mode set, but later discovered that it could be accessed with a fast access mode of `ide', the mount command would be: DEVICE=SFS.SYS ACCESS=IDE MOUNT=530A17FD The use of this option is only necessary if the volumes to be mounted have no alternative access mode associated with them, either by mksfs when the volume is created or by chsfs at a later point in time. However, if required, you can also use the `ACCESS=' option to override any existing access mode settings for the volume. To return to the default access mode settings, use the `ACCESS=DEFAULT' option, which sets the access mode of any volumes mounted after this point to the mode normally associated with the volume. For example if, in the previous two-volume mount example, you wanted to use the default access mode setting for the second volume instead of overriding it with an access mode of `ide', the volumes would be mounted as follows: DEVICE=SFS.SYS ACCESS=IDE MOUNT=530A17FD ACCESS=DEFAULT MOUNT=4850414B This would mount the first volume as before, and the second volume with whatever access mode was set for it by mksfs or chsfs. If a certain access mode is required in order to access a volume (for example some volumes on SCSI drives can only be accessed via SCSI access methods) then SFS will always use the appropriate access mode and ignore the current setting of the `ACCESS=' option. Like the other options which affect the mounting of volumes, you must specify the `ACCESS=' option before the `MOUNT=' which it is to affect. The `ACCESS=' option applies for all further mounts until another `ACCESS=' option is given. Changing the Characteristics of an SFS Volume --------------------------------------------- Once an SFS volume has been created, you can change various characteristics of the volume and the entire volume itself by using the chsfs program. chsfs allows you to change the SFS volume password or smart card password, volume name, disk access mode, auto-unmount timeout, and card removal action, allows SFS volumes to be quickly deleted, and allows the reversion of SFS volumes to their original unencrypted form. The chsfs program is run in the following manner: chsfs [newpassword] [newvolume=<new volume name>] [newtimeout=<timeout>] [newaccess=<new access mode>] [newcardcontrol=<action>] [delete] [convert] [volume=<volume name>] [<drive letter>] Since all arguments are named, you can give them in any order. The order shown here is merely an example. In addition, you can abbreviate all commands, so that for example you can give the `volume=' command as `volume=', `vol=', or even just `v='. The full commands are given in the documentation for completeness. In general you can specify the SFS volume to use by giving the volume's name with the `vol=' option. For example if the name was "Secure disk volume" then the command would be: chsfs <command> volume=secure You can give the name in upper or lower case and don't have to specify the full name, as chsfs will match whatever part of the name you supply to the names of any SFS volumes it finds until it finds a match. The SFS volumes are checked in the same order as they are displayed with the `mountsfs info' or `mountsfs information' command. Alternatively, if the SFS volume to be accessed is on a removable disk, you can specify it using its drive letter instead of its volume name. For example if the disk drive was A: then the command would be: chsfs <command> a: To find all available SFS volumes on all disks, you can use the `mountsfs info' option as explaind in the section "Mounting an SFS Volume" above. You can change the basic characteristics of an SFS volume with the `newpassword', `newvolume', `newaccess', `newtimeout', and `newcardcontrol' commands, which set a new password, new volume name, new disk access mode, new auto-unmount timeout, and new card removal action respectively. These commands can be used individually, or you can use several of them together (although they can't be used in conjunction with the `delete' or `convert' options). Their usage is in general similar to their use with mksfs or sfscard. `newpassword' takes no arguments and will prompt for the original password and then the new password, after which it will change either the volume password or the smart card password (depending on how the volume is accessed) from the original to the new one. `newvolume' takes as an argument the new volume name. `newaccess' takes as an argument the fast disk access mode obtained by running the mksfs program with the `-c' option, with the `bios' mode being the default, slower access mode. `newtimeout' takes as an argument the auto-unmount timeout setting in minutes, or `none' to clear the auto-unmount timer setting for this volume. `newcardcontrol' takes as an argument the action to be taken for the volume when the smart card it is associated with is removed from the card reader. The card control actions are `none', which does nothing, `readonly', which makes the volume readonly, and `unmount' and `unmountall', which unmount the given volume or all volumes. Since chsfs makes changes to the header record of an encrypted volume, some anti-virus programs may print a warning about the boot sector of the volume being changed (despite the fact that the volume is quite clearly not an MSDOS filesystem). This warning can be ignored. As an example, to change the name of the SFS volume "Personal data" to "Letters" and the auto-unmount timer setting to 30 minutes, the command would be: chsfs volume=personal newvolume=Letters newtimeout=30 If you use the `newpassword' option, chsfs will first ask for the old password: Please enter old password (10...100 characters), [ESC] to quit: or: Please enter old smart card password (10...100 characters), [ESC] to quit: depending on whether access to the volume is controlled by a smart card or not. You can now enter the password, which for security reasons is not echoed to the screen. You can correct any typing errors with the backspace key, and use the Esc key to quit. The software will check for a password longer than the maximum of 100 characters or an attempt to backspace past the start of the password, and beep a warning when either of these conditions occur. After verifying that the password is correct, chsfs will ask for the new password: Please enter new password (10...100 characters), [ESC] to quit: or: Please enter new smart card password (10...100 characters), [ESC] to quit: Like mksfs, chsfs will then ask for this password a second time for safety. Before updating the volume information, chsfs will perform the same multiple-overwrite operation used by the chsfs `delete' option (see below) to erase the original volume header, which is based on the old password. This ensures that no trace of the original disk access information remains before it is replaced by the new access information. This overwrite operation is not necessary for smart card keys as the card performs an automatic full erase cycle as part of writing the new data to the card. Once the new volume name, auto-unmount timeout, access mode, password, or card control action have been set, chsfs will display a message indicating the changes made. For the above example the message would be: Volume characteristics successfully updated. The new volume name is `Letters'. The new auto-unmount timeout is set to 30 minutes. Note that chsfs doesn't perform the checking for duplicate or nonexistant volume names and the checking for correct functioning of different disk access modes which mksfs does. This is to allow you to override the safe choices forced by mksfs if required[1]. You can make changes to the SFS volume itself using the `convert' and `delete' commands. `convert' converts a volume back to its original unencrypted form, and `delete' deletes it entirely, leaving behind what appears to the operating system as an unformatted disk filled with random noise. Since converting or deleting a volume while it is mounted is rather dangerous, chsfs checks whether the volume to be converted or deleted is currently mounted. If it is mounted and removable, it will prompt: Warning: This volume is currently mounted. Do you wish to unmount it and continue [y/n] At this point you can enter 'Y' to continue and 'N' to exit the program. If you enter 'N', you can unmount the volume using mountsfs or the quick-unmount hotkey before re-running chsfs. If the volume has been mounted as a fixed, non-removable volume, chsfs will exit with the error message: Error: This volume has been mounted as a non-removable volume and cannot be unmounted. In order for chsfs to be able to work with it, change the CONFIG.SYS entry for the SFS driver and reboot the machine. The delete option will first print the name and creation date of the SFS volume to be deleted. You should use this information to check the exact name and date of the volume to ensure that this is indeed the one to be deleted. In this example the volume information will be displayed as: Encrypted volume is `Incriminating evidence', created 04/11/93 If the volume is controlled by a smart card, chsfs will also print: Access to this volume is controlled by a smart card key. chsfs will now prompt for either the volume or smart card password in the usual manner. It uses this to check that access to the volume is legitimate, and is needed for chsfs to acquire various pieces of information it needs to perform the deletion. The program will then prompt: Warning: The deletion operation will permanently destroy all data on this volume. Are you sure you want to continue with the deletion [y/n] At this point you can enter 'Y' to continue and 'N' to exit the program. If you tell chsfs to continue, it will perform multiple overwrite passes over the SFS volume header (which contains all the information needed to access the volume), printing a progress report as it performs the overwriting: Overwriting: Pass 1 In total chsfs will perform 35 separate overwrite passes which have been selected to provide the best possible chances of destroying data for various disk encoding schemes (the exact details are given in the section "Deletion of SFS Volumes" below). Once the multiple overwrites have completed, chsfs will print an informational message about the deletion operation: Encrypted volume `Incriminating evidence' has been destroyed If the volume is on a fixed disk, you may want to reboot your machine to make the newly-deleted volume visible to DOS. Volumes on floppy disks will automatically be visible. Since the disk volume is now filled with random garbage, it will need to be formatted in the same way an unformatted disk would be before it can be used by DOS. The convert option will, like the delete option, first print the name and creation date of the SFS volume to be converted. You should use this information to check the exact name and date of the volume to ensure that this is indeed the one to be converted. In this example the volume information will be displayed as: Encrypted volume is `Disk data', created 07/12/93 If the volume is controlled by a smart card, chsfs will also print: Access to this volume is controlled by a smart card key. chsfs will now ask for the volume or smart card password in the usual manner, and will then prompt: Warning: You are about to convert this volume from an encrypted SFS one to a normal DOS one. Are you sure you want to continue with the conversion [y/n] At this point you can enter 'Y' to continue and 'N' to exit the program. Like mksfs, chsfs will then begin converting the disk. As it processes the volume, it prints a progress bar going from 0% complete to 100% complete. The conversion process will take a few minutes on most disks, and is somewhat slower than a standard disk formatting procedure, since the formatting process usually only writes a very small amount of data to the start of the disk and scans for bad sectors, whereas chsfs has to read, decrypt, and write the entire disk volume. As the conversion progresses, the progress bar will gradually fill up until it shows that the conversion is complete. Once this has finished, chsfs will display the message: Encrypted volume `Disk data' has been converted to a normal DOS volume. The converted volume is now ready to be used as a normal DOS disk again. If the volume is on a fixed disk, DOS will still think it is an encrypted SFS one rather than a normal DOS one. It is recommended that you reboot your machine to clear any memories of the old volume from the system, as DOS will not be able to see the converted volume until the reboot takes place. As a reminder, chsfs will display: You may wish to reboot your machine to update the status of the volume, which will become available as a standard DOS disk. before exiting. If the volume is on a removable disk, no reboot is necessary and chsfs will simply print: The volume is now available as a standard DOS disk. Footnote [1]: This makes the (possibly incorrect) assumption that the chsfs user knows what they are doing. Sharing SFS Volumes Between Multiple Users ------------------------------------------ At times it may be necessary to share a single encrypted SFS volume between multiple users. For instance several individuals may require access to a volume containing confidential business correspondence as part of their day-to-day duties. Usually this would require using a common password which is known to every member of the group of people who require access. The need to share passwords is a serious weakness, as the inability to choose individual, unique passwords increases the chances that a simple, easy-to-remember (and easy-to-guess) password is chosen, or that at least one person writes it down if it is too hard to remember. SFS solves this problem by allowing each member of the group access to an encrypted volume under their own individual password. The allocation of access rights to a volume is controlled by an administrator who can grant or revoke access as required. The administration process is handled by the adminsfs program, which is run in the following manner: adminsfs [adduser=<user name>] [deluser=<user name>] [chuser=<user name>] [showuser=<user name>] [showall] [validfrom=<DDMMYY>] [validto=<DDMMYY>] [userfile=<user file>] Since all arguments are named, you can give them in any order. The order shown here is merely an example. [!!!! That's all there is at the moment. adminsfs is still being checked out by beta-testers and parts of it are still under review. If anyone has any suggestions for it, let me know !!!!] Creating Compressed SFS Volumes ------------------------------- Creating a compressed drive inside an SFS volume provides, apart from the usual benefit of increasing the apparent disk space, some additional security against an attack by breaking up the very regular standard filesystem structure containing large quantities of known data at known locations into a compressed filesystem whose structure and contents are much harder to ascertain. This section contains information on using SFS with Stac Electronic's "Stacker" and JAM Software's "JAM". SFS and Stacker The instructions given here are for Stac Electronics "Stacker", although it should be possible to do the same thing with other reasonably advanced disk compressors. Stacker allows the compression of an entire DOS drive, or compression of any remaining free space on the drive. To create a compressed Stacker volume, you should first mount the SFS volume on which you want to install Stacker, either with the system-startup mount option of the SFS driver or with the mountsfs utility or SFS Control Panel item. You can then install Stacker in the usual manner onto the mounted volume. Under Windows, this involves chosing the "Compress" option from the "Stacker Toolbox", and under DOS it involves running the "stac.exe" program and picking the appropriate option, or using the "create.com" program on the drive to be compressed. Stacker will then defragment the drive, ask a few questions, and create the Stacker volume. When the Stacker drive has been created, the appropriate mounting parameters for the drive will be added to the STACKER.INI file. Once the installation has completed, the SFS volume will contain the STACKVOL file in which Stacker stores the compressed disk data. You can mount the Stacker drive in two ways, either from CONFIG.SYS onto an SFS volume mounted at system startup, or at a later point (which, however, means that it loads an extra copy of the environment variables). It is also possible to load the driver without activating a compressed drive by removing the specification for the drive to be mounted from the STACKER.INI file (this is normally used for floppies, but works for SFS as well since Stacker treats SFS volumes as a removable drive). You can then mount the drive at a later time with the "stacker <drive letter>" command, thereby avoiding the need to mount an SFS volume at startup. Under DOS 6, Stacker 4.0 loads using a device driver, but hooks into DOS like DoubleSpace/DriveSpace does. The rest of Stacker is then loaded with the STACHIGH.SYS driver. As SFS uses whatever drive letters DOS allocates to it, the stacked drive will take over the drive letter used by the SFS volume rather than swapping drive letters for the stacked and normal drive as it usually does. This shouldn't provide any problems when accessing the drive, as the compressed and encrypted drive will simply replace the encrypted drive, but it will create problems at a later point because Stacker uses the "Mount replaced" option, in which Stacker manipulates internal DOS data structures to completely replace the original SFS drive. This means that mountsfs can no longer find the mounted SFS drive for the "status", "info", "information", and "unmount" commands, although timed unmounts, hotkey unmounts, and smart card unmounts performed by the SFS driver itself will still work. SFS and JAM Using JAM Software's "JAM" compressor with SFS is somewhat simpler than using Stacker, and provides the additional benefit of speeding up effective disk access times since the high-speed JAM software reduces the amount of data which the SFS driver needs to encrypt. To create a compressed JAM volume, you should first mount the SFS volume on which the JAM volume is to be installed, either with the system-startup mount option of the SFS driver, with the mountsfs utility, or with the SFS Control Panel item. You can then create the compressed volume as described in the JAM documentation with the JCREATE utility. Once you have created the compressed disk volume, you can mount it by loading the JAM.SYS driver via the CONFIG.SYS file and then mounting the JAM volume with the JMOUNT utility, either onto an SFS volume mounted at system startup by running JMOUNT from the CONFIG.SYS file, or at a later point by running JMOUNT from the command line. This avoids the need to mount an SFS volume at startup. Unlike Stacker, JAM does not mess with DOS drive letters, allowing both the SFS volume and the JAM volume it contains to be accessed as normal. JAM is available for FTP from garbo.uwasa.fi and all garbo mirrors as /pc/arcers/jam125sw.zip. Emergency Access to Encrypted Information ----------------------------------------- It may sometimes be necessary to provide access to encrypted data without the use of the passphrase used to encrypt it, perhaps because the passphrase has been forgotten or the person who encrypted the data has died or moved on to work for another company. This provides a backup means of access to encrypted data in case of an emergency. The approach taken by the US government, in the form of the Clipper initiative, is to have all encryption keys (not just those for which emergency access is required) held in escrow by the government. If disclosure of the information is required, the key is retrieved from storage and used to decrypt the information. A side effect of this is that any data which has ever been encrypted with the key, and any data which will ever be encrypted in the future, has now been rendered unsafe. This system is best viewed as uncontrolled disclosure. In addition, there is no possibility of ever having completely safe data since someone else will always hold a copy of your encryption keys. SFS includes a built-in mechanism for fully controlled access to encrypted data so that, if access is ever required without the proper passphrase being known, only the information for which access is authorized may be revealed. All other encrypted data remains as secure as it was previously. This is achieved by encrypting each disk volume with a unique disk key which is completely unrelated to the users passphrase, or key. When the user key is entered, it is used to decrypt the disk key, and the disk key is then used to decrypt the encrypted volume. There is no correlation between the user key and the disk key, so that revealing the disk key does not reveal the user key. This access mechanism looks as follows: + User - - - + + Encrypted volume - - - - - - - - - - - - + | +--------+ | decrypt | +--------+ decrypt +--------------+ | |User Key| -----------> |Disk Key| -----------> |Encrypted Data| | +--------+ | | +--------+ +--------------+ | + - - - - - - + + - - - - - - - - - - - - - - - - - - - - - + A simple way to use this keying mechanism for key escrow is to store the disk key for the volume in a safe place, and allow it to be entered directly in place of the usual user key. Since the user key is independant of the disk key, it can be changed as often as required while still allowing access via the escrowed disk key. The person using the encrypted data can change and modify the user key as they please without inadvertently locking out the holder of the escrowed disk key. Therefore there are now two ways to access the encrypted volume: + User - - - + + Encrypted volume - - - - - - - - - - - - + | +--------+ | decrypt | +--------+ decrypt +--------------+ | |User Key| -----------> |Disk Key| -----+-----> |Encrypted Data| | +--------+ | | +--------+ | +--------------+ | | + - - - - - - + + - - - - - - - - | - - - - - - - - - - - - + | + Escrow - - - - - - - - - + | | | +----------------------+ | | |Non-encrypted Disk Key| ---------------+ | +----------------------+ | + - - - - - - - - - - - - - + Unfortunately, storing a non-encrypted disk key which allows access to a volume is rather dangerous since it creates a convenient point of attack. Whereas the user key is usually stored in a reasonably secure place - human memory - the escrowed disk key or keys would typically be recorded in some manner and stored in (hopefully) secure location such as a safe. Anyone who gains access to the safe will have access to the encrypted volume. In addition, the escrowed key provides a single point of vulnerability to accidental damage such as destruction by fire. A solution to this problem is to escrow not a single key but multiple key fragments. The established practice of needing multiple keys held by different people to open a safe can be used for encryption as well - simply take a single key, break it into a number of pieces, and give one piece to each member of a group of people. To access the data, the group combines their partial keys into one whole key, and the data is decrypted[1]. For example, if a company president who holds the keys to a safe or data dies suddenly, the vice-presidents can combine their partial keys to allow access. The previous access diagram now becomes: + User - - - + + Encrypted volume - - - - - - - - - - - - + | +--------+ | decrypt | +--------+ decrypt +--------------+ | |User Key| -----------> |Disk Key| -----+-----> |Encrypted Data| | +--------+ | | +--------+ | +--------------+ | | + - - - - - - + + - - - - - - - - | - - - - - - - - - - - - + | +----------------+ | + Escrow - - - - - - - - - - - - - - - - - - - - - - - - + | | | +--------------+ | | |Key fragment 1| --+ | | |Key fragment 2| --+ combine +----------------------+ | | |Key fragment 3| --+---------> |Non-encrypted Disk Key| ---+ | | ... | | +----------------------+ | |Key fragment n| --+ | +--------------+ | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - + This method has one serious shortcoming, which is the requirement that all the keyholders meet to recreate the original key. If one keyholder is killed in an accident, or loses or forgets their key fragment, or refuses to give it up, recreation of the original key becomes impossible. SFS solves this problem by allowing redundant key fragments to be held in escrow, so that only a certain percentage of the total number of fragments need to be recombined to recreate the disk key. For example, a key may be broken into 5 fragments of which any 3 can be used to recreate the disk key. A company director might give the 5 fragments to the board of directors so that, if anything were to happen to him, any 3 of the 5 could get together and access his encrypted data. The SFS key escrow features are handled by chsfs (to create the key fragments for escrow) and mountsfs (to access the encrypted data using the escrowed key fragments). There are two escrow parameters: - The total number of fragments to break the key into - The quorum, or number of fragments needed to recover the key. This may be anything up to and including the total number of fragments. For the best damage resistance, it is recommended that you choose a quorum which is somewhat less than the total number of fragments in case one or two of the fragments are lost. Technical details on the secret sharing scheme used by SFS are given in the section "Safeguarding Cryptographic Keys" below. Footnote [1]: The US government's Escrowed Encryption Standard works like this, with partial keys being held by two seperate government organisations. Creating Escrow Keys with chsfs The creation of key fragments for escrow is handled by the chsfs `splitkey=<quorum>/<total>' command, where <quorum> is the number of key fragments needed out of the <total> to reconstruct the disk key. Using the previous example in which 3 fragments out of the total of 5 are needed to recreate the disk key, the chsfs command would be: chsfs splitkey=3/5 volume=data which would take the disk key for the indicated volume and split it into 5 fragments. In its simplest form, `splitkey=1/1' creates just one key fragment equivalent to the whole key. Before it splits the key, chsfs will prompt: The distributed key which will be created will contain 5 fragments, of which at least 3 will be needed to allow access to the SFS volume. This means that up to 40% of the total number of fragments can be lost or destroyed before access to the encrypted volume becomes impossible. Are you sure you want to use these parameters [y/n] At this point you can enter 'Y' to continue and 'N' to exit the program without creating the key fragments. chsfs will now ask for the volume or smart card password in the usual manner: Please enter new password (10...100 characters), [ESC] to quit: or: Please enter new smart card password (10...100 characters), [ESC] to quit: You can now enter the password, which for security reasons is not echoed to the screen. You can correct any typing errors with the backspace key, and use the Esc key to quit. The software will check for a password longer than the maximum of 100 characters or an attempt to backspace past the start of the password, and beep a warning when either of these conditions occur. After verifying that the entered password is correct, chsfs will break the key into the required number of fragments, write them to disk in the current directory, and recombine them and compare the recovered key to the original as a check to ensure the key can be recovered from the fragments. Once this self-checking process has finished, it will display the message: Key fragments successfully written to disk. The key fragments are stored in files of the format `xxxxxxxx.yyy', where `xxxxxxxx' is an 8-digit random value used to identify related files, and `yyy' is the number of the key fragment. These values aren't terribly important or critical, but are merely used for bookkeeping purposes. These key fragments contain critical information used for accessing encrypted volumes. Anyone in posession of enough fragments to recreate the disk key can gain access to the encrypted data it protects, so you should try to disperse the fragments *immediately*. Ideally, you should only create the fragments when the current directory is on a RAM drive, so that they are never written to a hard drive or floppy drive in one group, although writing them to an encrypted SFS volume is also a possibility if no RAM drive is available. You can then copy them to seperate floppies, possibly with encryption, and disperse them to the people or sites that will act as escrow agents. The sequence of steps to follow for the best security is therefore: 1. Change drive and directory to a RAM drive (preferred) or an SFS drive. 2. Run chsfs with the splitkey option to create the key fragments. 3. Encrypt the fragments if necessary. 4. Copy individual fragments to the distribution media, for example floppy disks. 5. Overwrite the originals on the RAM drive or SFS drive, or reboot the machine to clear the data if it's on a RAM drive[1]. If writing the fragments to an unencrypted hard drive is unavoidable, you should overwrite them with a secure file erasure program as soon as possible. The difficulty of truly erasing data on magnetic media is covered in the section "Deletion of SFS Volumes" below. Accessing Encrypted Data using Escrowed Key Fragments The first step in accessing an encrypted volume using escrowed key fragments is to recombine enough of the fragments to recreate the key. You can do this by copying the key fragments into one place, if possible a directory on a RAM drive, or an SFS drive if one is available, as was used for the key dispersion process described above. To use the key fragments instead of the usual passphrase to mount a volume, run mountsfs with the `-c' combine option, which can also be used for any mountsfs and chsfs commands which would normally require the passphrase to be entered, such as the `chsfs newpassword' or `chsfs convert' commands. In this case when mountsfs is used, the command to mount the disk volume used in the previous key dispersion example using the escrowed key fragments would be: mountsfs -c volume=data mountsfs will then scan the current directory looking for key fragments. If it can't find any key fragments for the volume in question, mountsfs will exit with the message: Error: Couldn't find any of the key fragments needed to recreate the encryption key. If one or more groups of key fragments are found, but none of the groups contain enough fragments to allow the disk key to be recovered, mountsfs will display more specific information for each group of shares. For example, assume that three groups of shares are created with the parameters: chsfs splitkey=5/8 chsfs splitkey=3/5 chsfs splitkey=2/3 These are then dispersed to third parties acting as escrow agents. When access to the encrypted volume is required, some of the shares from each of the three groups are obtained from the escrow agents, and mountsfs is run on them, with the following results: Warning: Couldn't find enough key fragments in the first set of shares to recreate the encryption key, since at least 5 fragments are needed, but only 3 were found. Warning: Couldn't find enough key fragments in the second set of shares to recreate the encryption key, since at least 3 fragments are needed, but only 2 were found. Warning: Couldn't find enough key fragments in the third set of shares to recreate the encryption key, since at least 2 fragments are needed, but only 1 was found. Error: Couldn't find any more key fragments to use to try to recreate the encryption key. In this case there are not enough shares present from any of the three groups to allow the disk key to be recovered. Two more fragments are needed to recover the key from the first group, and one more fragment is needed to recover the key from the second and third group of shares. Otherwise, if mountsfs can recover the disk key from the key fragments, it will display the message: Disk key has been recovered from key fragments and mount the volume as usual. Since this method of access is meant for emergencies only, you should assign a new passphrase to the volume as soon as possible. You can do this by running chsfs with the `-c' combine option, which works exactly like the mountsfs `-c' option. If run with the `newpassword' command, chsfs will recreate the disk key from the key fragments as mountsfs did, and then prompt for and set a new user password as it normally would. You can also use the `-c' option with other chsfs commands such as `delete' and `convert'. As soon as the volume has been mounted or modified as required, you should destroy the key fragments on the RAM drive or SFS drive by wiping them with a secure file erasure program, or rebooting the machine to clear the data if it is stored on a RAM drive[1]. Footnote [1]: In fact, rebooting a PC will not necessarily wipe a RAM disk. Turning the machine off for 5-10 seconds (some DRAM cells can retain data for an amazingly long amount of time, often more than a second) to clear the memory is a better idea.